昨天做完第二次小結,交代了接下來要轉進 AI 主線。今天想先把「呈現與回應」這條線收個尾：事件回應的六個階段大致長怎樣,以及同一筆事件,寫給不同的人看,會長成完全不同的樣子。

六個階段
準備：先確保採集正常、稽核政策開著、有基準可以比對
偵測與分級：告警出現後依基礎分加升降因子分級,判斷是不是命中了關聯型樣
控制：如果嚴重就先隔離主機、封鎖來源、凍結帳號
根除：移除持久化、清掉惡意檔案
復原：重設憑證、驗證乾淨後復原服務
檢討：最後回饋規則、補關聯規則、寫報告

老實說,這六階段目前我沒有走過一次完整的真實事件——我遇到的都是規則測試或誤判排查,沒有真的發生過需要隔離主機、封鎖來源這種控制、根除層級的處置。真正走過的,其實是最後一個階段：檢討...
Day 8 那次發現規則掛錯父規則、回頭修規則,Day 9 那次量化噪音、設計降噪規則,某種意義上都是「檢討→回饋規則」這個循環的真實案例,只是觸發原因不是真的攻擊事件,是我自己在測試跟排查過程中發現的問題。

同一件事,寫給不同的人
我另外設計了幾種報告模板,分主管版、技術版跟 Demo 版。 核心邏輯是：同一份事件,對象不同,該講的東西完全不一樣——主管版要少術語、聚焦業務衝擊跟需要的決策;技術版要給 Event ID、欄位證據、technique id 這些可以據以行動的細節。 兩者都要誠實講不確定的地方,差別只在詳細程度,不是誠實程度的差別。

與其又貼一次帶佔位符號的範例,不如拿 Day 4、Day 8 那條我真的驗證過的事件鏈,實際套一次這兩種模板,看看差異具體長怎樣。

主管版:

事件主管摘要

• 發生了什麼:一個帳號在系統上被新增,隨後短時間內被加入本機管理員群組。
• 影響範圍:該台受監控主機及其本機權限範圍,尚未觀察到進一步擴散。
• 風險程度:高 —— 新增帳號並立刻取得管理員權限,是常見的持久化與提權手法。
• 已採取行動:此事件為授權測試情境下的驗證,測試帳號已於驗證後移除。
• 需要的決策/資源:若為真實情境,需要核准後續調查該帳號建立者的身分與意圖。
• 目前狀態:已解決(測試情境)。
  技術版:

技術分析報告

• 事件鏈:4720(帳號建立成功)→ 4732(加入本機 Administrators)
• 欄位證據:rule.id 110121(level 8)→ rule.id 110160(level 14,關聯規則);
  110160 之 if_sid 依賴 110131,證明 4732 已先命中該父規則
• MITRE:T1136(Create Account)→ T1098(Account Manipulation)
• IOC:無外部來源 IP 涉入(本次為本機操作驗證)
• 偵測機會:已對應 C2 型樣(建帳號→加特權群組);規則命中判定精確度見 Day 17 的
  SID 正規化限制(目前用同操作者近似,非直接比對帳號欄位)
• 誤判評估:授權測試操作,非真實誤判案例
• 處置:測試帳號已於驗證後自 Administrators 移出並刪除
• 待確認:rule.id 為 env-specific,僅適用本機環境

兩版用的是同一組事實,但技術版能讓分析人員直接去查 rule.id 110160、對照 Day 17 提過的 SID 精確度限制;主管版完全不需要知道 rule.id 是什麼,只需要知道風險程度跟需要核准什麼。

Demo 版我這裡先不寫。 Day 15 已經老實講過,demo 劇本裡完整的攻擊鏈(RDP 暴力破解→成功→建帳號→提權)只有後半段真的驗證過,前半段還沒模擬過。如果現在就寫一份「完整」的 Demo 報告,等於是把還沒發生的事寫得像已經發生——這正是 Day 15 那次犯過、後來改掉的錯,這裡不重蹈覆轍。等 RDP 那段真的測過,再回頭補這個版本。

明天
接下來系列要正式轉進 AI 這條主線。第一篇想先劃清界線：AI 在這個系統裡該做什麼、絕對不該做什麼。

明天見。